(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 
International Bureau 

(43) International Publication Date 
9 October 2003 (09.10.2003) 




(10) International Publication Number 

PCT WO 03/083751 Al 



(51) International Patent Classification': G06F 17/60 

(21) Internationa! Application Number: PCTAJS03/06581 

(22) International Filing Date: 3 March 2003 (03.03.2003) 

(25) Filing Language: English 

(26) Publication Language: English 



(30) Priority Data: 






60/367,698 


26 March 2002 (26.03.2002) 


US 


10/184,033 


26 June 2002 (26.06.2002) 


US 


10/184,031 


26 June 2002 (26.06.2002) 


US 


10/184,012 


26 June 2002 (26.06.2002) 


US 


10/184,030 


26 June 2002 (26.06.2002) 


US 



(71) Applicant: FIRST DATA CORPORATION [US/US]; 
12500 East Belford Avenue, Suite M21 A2. Englewood, CO 
801 12-5939 (US). 

(72) Inventors: SWIFT, Amy; 6316 Puma PI. NE, Albu- 
querque, NM 87111 (US)..TIDWELL, Lisa; 11511 Echo 
Hollow Street, Houston, TX 77024 (US). MOLLETT, 
Cassandra; 1735 Lexington, Houston, TX .77098 (US). 



(74) Agent: DELANEY, Karoline, A.; KNOBBE, 
MARTENS, OLSON & BEAR, LLP, 2040 Main Street, 
14th Floor, Irvine. CA 92614 (US). 

(81) Designated States (national): AE, AG, AL, AM, AT, AU, 
AZ, BA, BB, BG, BR, BY, BZ, CA, CH, CN, CO, CR, CU, 
CZ (utility model), CZ, DE (utility model), DE, DK (utility 
model), DK, DM, DZ, EC, EE (utility model), EE, ES, FI 
(utility model), FI, GB, GD, GE, GH, GM, HR, HU, ID. BL, 
IN, IS, JP, KE, KG, KP, KR, KZ, LC, LK, LR, LS, LT, LU, 
LV, MA, MD, MG, MK, MN, MW, MX, MZ, NO, NZ, OM, 
PH, PL, PT, RO, RU, SC, SD, SE, SG, SK (utility model), 
SK, SL, TJ, TM. TN. TR, TT, TZ. UA, UG, UZ. VC. VN, 
YU.ZA.ZM.ZW. 

(84) Designated States (regional): ARIPO patent (GH, GM, 
KE, LS, MW, MZ, SD, SL, SZ, TZ, UG, ZM, ZW), 
Eurasian patent (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), 
European patent (AT, BE, BG, CH, CY, CZ, DE, DK, EE, 
ES, FI, FR. GB, GR, HU, IE. IT. LU, MC, NL. PT. RO, 
SE, SI. SK, TR), OAPI patent (BF, BJ, CF, CG, CI, CM, 
GA. GN. GQ, GW, ML. MR. NE. SN, TD, TG). 

Published: 

— with international search report 

[Continued on next page] 



(54) Title: 
MSM 



ALTERNATIVE PAYMENT DEVICES USING ELECTRONIC CHECK PROCESSING AS A PAYMENT MECHA- 



USER CHECK 



100 



MICRUNE 



ENROLLMENT 
FORM 



t> 
00 

o 
O 



130. 



DEBIT 
ACCOUNT 



USER 
ENROLLMENT 
SYSTEM 



110 



USER DEBIT DEVICE 
(RF TRANSPONDER) 

1 



120- 



CLEARINGHOUSE SYSTEM 



TJ 



MICROATA 








U . . 1 
AUTHORIZATION 

1 » 




CREOrrED 
ACCOUNT 


~135 


MERCHANT 


SYSTEM 




p 105 



140-1 



MERCHANT 
RECEIVER 



SERVER 



148- 



I WEB \ 

|docs_J 

^ 146 



USER 
ACCOUNT 



I DEVICE ID 1 



SERVER 
CODE 

1. ENRoaMErrr 

PROCESS 

2. PURCHASE 
PROCESS 




TRANSACTION PROCESSOR 



-158 



SERVER 



HISTORICAL 
TRANSACTION 
DATA _ 



MICR 
CONVERSION 
DATA 



SERVER CODE 

1. TRANSACTION 
PROCESSING 
PROCESS 

2. ENROUMENT/ 
PURCHASE 
PROCESSING 



(57) Abstract: The present invention includes a merchant system (1Q5) that recognizes virtually any payment device (120) or tech- 
nology that uses electronic check processing as a payment mechanism. For example, the merchant system ( 105) associates presenta- 
tion of the payment device (120) with information used to electronically debit a checking account, such as MICR data, and submits 
the same to a transaction processor (115) capable of setding electronic debit transactions. 
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ALTERNATIVE PAYMENT DEVICES USING ELECTRONIC CHECK PROCESSING AS A PAYMENT 

MECHANISM 

FIELD OF THE INVENTION 

The present invention relates to the field of electronic commercial transactions. More specifically, 
the invention relates to merchant systems designed to recognize alternative payment devices that use 
electronic checlc processing as a payment mechanism. 

BACKGROUND OF THE INVENTION 

Consumers and merchants in toda/s marketplace have access to a wide variety of technologies for 
extending credit or otherwise transfem'ng monies for goods or services (''products"). For example, consumer 
and merchants use traditional debit technologies such as paper checks. A check refers to a draft or order for 
a certain sum of money payable on demand to a certain named entity, the entity's order, or to the bearer 
thereof Generally, the face of a check includes magnetic ink character recognition ("MICR") characters that 
can be read electronically. The MICR characters typically Include a checking account number, the bank 
transit number, the check sequence number, and the like. In addition, the MICR characters may indicate 
whether the check is a company check or a personal check. The fonn or font of the MICR characters and 
their position along the bottom edge of the check are generally prescribed by standards promulgated by the 
American National Standards Institute ("ANSI"), which are incorporated by reference herein. 

Paper checks are generally processed through clearinghouse ("ACH") networtcs, which can include 
some or all banks, clearinghouse corporations, the Federal Reserve bank, or the like. For example, a payor, 
or check writer, may authorize an originator, such as a grocery store, to debit the payor's checking account by 
writing a check for, for example, groceries. The originator forwards the authorization to an originating 
depository financial institution f ODFI"), such as the grocer's bank. The ODFI sends the authorization thmugh 
the ACH networic to a receiving depository financial institution ("RDFr), such as the payor's bank. The RDFI 
then can transfer funds by debiting the payor's checking account and sending a credit through the ACH 
networic to the ODFI, or grocer's bank. 

To avoid many drawbacks associated with the foregoing paper check processing, such as 
processing delays measured in many days and sometimes in one or more weeks, ACH networics now provide 
for electronic check processing. For example, merchants can now have personal checks converted to 
electronic ACH debits, often by scanning in paper check data at the point-of-sale, and returning the paper 
copy of the check to the consumer. The paper check data generally includes data representing the MICR 
characters, an amount, a payee, a scan of one or both sides of the paper check, and the like. As can be 
expected, the electronic ACH debits can be processed at much greater speeds due at least in part to the lack 
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Of paper handling that will occur. Moreover, some i)anks are processing a day's electronic items prior to 
processing the da/s paper Hems. 

The decreased processing delays associated with the electronic ACH debits often advantageously 
provide more consistent deposit patterns back to merchants and decrease the delay In discovering and 
slopping the use of firaudulent checks. Additionally, as discussed in the foregoing, electronic ACH debits also 
advantageously allow merchants to immediately return the paper check to the customer. 

Other technologies available to consumers and merchants in today's mari(etplace include traditional 
credit and debit card technologies. While these traditional card technologies enjoy wide acceptance as a 
method of paying for products both in modem online and traditional paper processing environments, they 
have significant drawbacks for consumers and for merchants. For example, as compared with the b^ 
population, a much smaller percentage of consumers have or use one or more credit or debit cards. 
Moreover, the issuer of card technologies often charges high interest rat^ to the consumer, while also 
charging high fixed or high variable processing fees to merchants. The high rates often render smaller 
incremental charges via traditional card technotogies impractical. Also, more and more consumers are unable 
or unwilling to pay down their debt, so they resort to revolving that debt from one credit card to the next In 
addition to the foregoing, traditional card technologies can be subject to fraud, fines, or the like. 

Still other technologies available today include modem payment technologies, such as. convenience 
or toyalty cards, radto frequency payment devices such as Easypay. Speedpass. Fastoay, toll road 
transponders, or the like. Generally, a consumer first enrolls in a payment technology with a merchant or a 
20 gateway service. During enrollment., the consumer often provktes a credit or debit card account from which 
debite will be m ade. The merchant then issues, for example, the payment d evice to the consumer. When the 
corisumer desires to purchaWpriducte from the mercharit. the ronsumer presente the payment devicelo. for 
example, a receiver devtee designed to communicate with the payment device so as to uniquely identify the 
consumer's associated credit or debit card account. The merchant then bills the consumer's card for the 
25 purchase of the products. 

The foregoing payment technologies are finding wider acceptance among consumers as the 
payment technologies often provide a very convenient payment mechanism, and are finding wider acceptence 
among merchants as payment technologies often generate consumer loyalty. However, because the 
foregoing payment technologies often employ traditional cant technologies as the backend payment 
30 mechanism, these payment technologies unfortunately assume many or all of the foregoing drawbacks 
associated with the traditional card technologies, including, for example, the inability to practteally sennce 
smaller, incremental-type charges. 
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SUMMARY OF THE INVENTION 
Based at least in part on the foregoing drawbacks, a need exists for transaction processing system 
that allows consumers to use modem payment technologies without incorporating the drawbacks of traditional 
credit or debit card technologies. One embodiment of the invention includes a transaction processirig system 
5 that converts a transaction pmduced from virtually any payment device or technology, into electronic debits 
processed through clearinghouse systems as traditional electronic ACH debits to a checking account. Thus, 
the transaction processing system advantageously avoids the negative drawbacks of traditional credit or debit 
card technologies while incorporating the advantages of electronic ACH debit processing. Moreover, by using 
a checking account for the debit, the transaction processing system advantageously uses the most prevalent 
10 financial account found in the U.S. population. According to some embodiments, the transaction processing 
system also provides for the guarantee of payment to the merchant or retailer initiating the transactions. 

According to one embodiment, the transaction processing system includes a merchant system, a 
transaction processor, an automated clearinghouse system and a user account. The transaction processor 
accepts enrollment transaction requests from merchant systems seeking to issue a payment device to a new 
15 user, where the payment device is other than a.paper check and designed to access debit funds in the user's 
checking account For example, the payment device can include cards, transponders, biometric elements, or 
the like. During enrollment processing, the transaction processor accepts user data, MICR data^ the check 
number, and the like. The transaction processor also accepts a transaction date and merahant data, such as 
a merchant's identification number or other data. 
20 According to one embodiment, the transaction processor processes enrollment transaction requests 

by validating some or all of the user data, by clearing some or all of the user data through negative and/or 
positive databases, assessing a risk score to the enrollment transaction using, for example, a variety of payor 
historical payment variables as well as variables associated with typical transactions in that standard industry 
code (SIC - a four digit code often used to denote differing specific industries), validating MICR data through 
25 ACH processing, or the like. The transaction processor retums a result of the enrollment transaction to the 
merchant. According to one embodiment, the result can include advice on whether to an accept or decline 
the user, an assessed risk score associated with enrolling the user, a result of a negative and/or positive 
database search, some or all of the same, or the like. 

According to another embodiment, the transaction processor also accepts purchase transaction 
30 requests from merchant systems that have recognized, a payment device presented by a user as payment for 
a product For example, the merchant system can associate a presented payment device with a unique user 
account directing the merchant to withdraw funds to cover payment from the user's checking account. The 
merchant system organizes the infonnation into a purchase transaction request and fonvards the same to the 
transaction processor. During the processing of purchase transactions, the transaction processor accepts 
35 data, such as some or all of the foregoing user data, some or all of the foregoing MICR data, some or all of 
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the foregoing merchant data, or the like. THe transaction processor also accepts specific transaction data 
such as the date, time or amount of the tiansactioa the product information involved in the transaction, and 
the like. The transaction processor also submits one or more electronic ACH debits representing the 
transac^on to the clearinghouse system. 

Moreover, in an embodiment, the transaction processor processes purchase transaction requests by 
validating some or ail of the submitted user data, by clearing some or all of the user data through negative 
and/or positive databases, by assesslng a risk score to the enrollment transaction, by settling the transaction 
through electronic ACH debit processing, and the like. The transaction processor returns an authorization 
result of the payment transaction to the merchant. For example, the result can include advice on whether to 
accept or decline the purchase transaction based on an assessed risk score associated with transactfon. a 
result of a negative and/or positive database search, some or all of tiie same, or ttie like. 

In one embodiment, the merchant may manage the payment device, such as a proprietary loyalty 
card, thereby allowing the users to purchase products at the merchanfs retail locations using the payment 
device. Additionally, acconling to at least one embodiment, a "gateway" can act as an aggregator of senrices 
and provide multiple merchants witti the ability to alfow payment through the gateway's payment devfce. For 
example, the gateway may altow users to purchase products at for example, many differing merchants' retail 
locations using the same payment device. 

For purposes of summarizing the invention, certain aspects, advantages and novel features of the 
Invention have been described herein. It is to be underetood that not necessarily all such advantages may be 
achieved In accordance witt) any particular embodiment of the invention. Thus, tite invention may be 
embodied or car ried out in a manner that achieves or optimizes one adj^nt^e or group o f advantages as 
taFgW heriln wltfiMneceM^affly a^^^^ taught or sugg^'hereinr ^ " 

BRIEF DESCRIPTION OF THF nRAWIKir^c; 
25 A general architecture tfiat implements flie various features of tfie invention will now be described witfi 

reference to the drawings. The drawings and tiie associated descriptions are provided to illustrate 
embodiments offlie invention and not to limitthe scope of tfie invention. Throughout ttie drawings, reference 
numbere are re-used to indicate conespondence between referenced elemente. In addition, the liret digit of 
each reference number indicates the figure in which the element fifst appears. 

FIGURE 1 illusbates a diagrammatic representation of an exemplary transaction processing system 
which allows a user to present payment technologies ottier than checks or credit cards and have payment 
extracted from a debit account, according to an embodiment of ttie invention. 

FIGURE 2 iilusbates an exemplary webpage used to enroll ttie user in ttie transaction processing 
system of FIGURE 1, according to an embodiment of the invention. 

J5 FIGURE 3 illustrates an enrollment process, according to an embodiment of ttie invention. 
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FIGURE 4 illustrates a purchase process, according to an embodiment of the invention. 

FIGURE 5 Illustrates a transaction processing process, according to an embodiment of the Invention. 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS 
5 A transaction processing system converts the presentation of virtually any payment device or 

technology, into electronic debits to a checking account processed through a clearinghouse system. Thus, 
the transaction processing system advantageously avoids the negative drawbacks of traditional credit or debit 
card technologies while incorporating the advantages of electronic debit processing. Moreover, by using a 
checking account, the transaction processing system uses the most prevalent financial account found in the 
10 banking population. 

As will be apparent, many of the disclosed features may be used without others, and may be 
implemented differently than described herein. Further, although described primarily in the context of a 
transponder based system, the various inventive features are also applicable to types of alternative payment 
devices other than paper checks or credit or debit cards, including, but not limited to loyalty cards, electronic 
IS wallets, one or more smart cards, one or more biometric elements such as a thumbprint or facial recognition, 
other point-of-sale payment devices, or the like. The following description is thus Intended to illustrate, and 
not limit, the invention. 

According to one embodiment the transaction processing system includes a merchant system, a 
transaction processor, a user payment device, a clearinghouse system, and a user debit accourit. The 

20 transaction processor accepts enrollment transaction requests from merchant systems seeking to issue a 
payment device to a new user, such as a potential payor, where the payment device is other than a paper 
check and designed to access debit funds in the user's debit account, such as a checking account For 
example, the user can include an individual consumer attempting to make a financial transaction. The 
payment device can comprise a convenience or loyalty card, a transponder, such as radio or other frequency 

25 transponder, an electronic wallet, one or more smart cards, one or more biometric elements such as a 
thumbprint or facial recognition, other point-of-sale payment devices, or the like. During enrollment 
processing, the transaction processor accepts user data, such as driver's license number or other 
identification infonnation, demographic inforination such as name, address, birth date, telephone number, 
social security number, or the like, one or more biometric measurements, passwords, or the like. The 

30 transaction processor also accepts MICR data such as scanned or manually entered MICR characters from 
an unused paper check of the user, the check number, or the like. The transaction processor also accepts a 
transaction time, place and date, and merchant data, such as a merchant's identification number, location, or 
other data. 

35 ENROLLMENT TRANSACTIONS 

'5- 



wo 03/083751 



PCT/US03/06581 



15 



20 



25 



30 



According to one embodiment, the transaction processor processes enrollment transaction requests 
deperjding upon sennces generally chosen by the submitting merchant. For example, a meix:hant may chose 
to hav9 some or all of the user data validated. According to one embodiment, the transaction processor can 
detemiine whether user data, such as. for example, driver's license infomiation. driver's license infbmiation. 
5 MICR data, or the like mateh those contained in one or more databases accessible to the transaction 
processor. For example, the transaction processor may access a wide number of sources, including credit 
agencies, online infomiation or databases, public records, or the like. According to one embodiment, some or 
all of the user data, social security number, MICR data, or the like is provided by the user during enrollment 
According to one embodiment, a merchant may also choose to have the transaction processor clear 
10 some or all of the user data through negative and/or positive databases. For example, the transaction 
processor can compare the user's name, driver's license infomiation. or other demographic infomiatton to a 
database of known high risk (negative databases) or known low risk (poslfive databases) data. When a 
match is Ibund in the negative databases and the merchant desires that the transactton processor guarantee 
future transactions associated with the enroOing user, the transaction processor may infomi the merchant 
system to decline enrollment to the user. Alternatively, when the processor is hot acting as a guarantor, the 
transaction processor may return infomiatlon infomiing the merohant of. for example, a negative datebase 
match. 

A merchant may also choose to have the transaction processor assess a risk score for the 
enronment transactton. As in known in the art. assessing a risk score can advamageously include predictive 
modeling systems that analyze a plurality of relevant variables in order to detemiine the probability of a 
^'^9 good or bad. such as the probability the bansac?fion wll or will not clear the 
banking system via clearinghouse processing. 

Credit risk scoring algorithms generally take into account those pieces of available data that have 
been detemiined to be statistically significant. The risk score may be a nomialized value that indicates the 
probabBify that the transaction will be good. If the merchant desires that the transaction processor guarantee ' 
future transactions associated with the enrolling user as well as process the transaction, the transaction 
processor may simply advise the merchant whether to decline enrollment to the user based on. for example, 
whether the risk score meets a predetemiined threshold. Altemalively. If the transactton processor Is not 
acting as a guarantor, the transaction processor may compare a merchanfs 'score card.' whfch Includes 
predetemiined values below which the merchant and/or the processor agree, the risk of loss is acceptebte to 
the merchant. Othenwise. the transactton processor may simply return the risk score to the merchant system. 
Although risk scoring algorithms are known in general. It will be appreciated , that the deteils of most 
algorithms, including the specific data considered and the weight given various date, are considered 
proprietory by their owners. 
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The merchant may also choose to have the transaction processor validate any ACH processing data: 
According to one embodiment, the transaction processor can perfonn a validation transaction where a user's 
checlcing account is debited and credited for. for example, an equal amount. The result of such debiting and 
crediting can be reported through, for example, settlement files similar to those to be discussed with reference 
5 to purchase transactions. The foregoing validation transactions ensure that the user's account and the 
associated banking institutions are compatible with the processing of electronic ACH debits. 

PURCHASE TRANSACTIONS 

According to another embodiment, the transaction processor also accepts purchase transaction 
10 requests from merchant systems that have recognized a payment device presented by a user as payment for 
a product. The merchant system associates the device with a unique account directing the merchant to 
withdraw funds to cover payment from the user's debit account. During purchase processing, the transaction 
processor accepts data, such as some or all of the foregoing user data, some or all of the foregoing MICR 
data, some or all of the foregoing merchant data, or the iilce. The transaction processor also accepts data 

1 5 related to the specific transaction, such as product infonnation. amount of purchase, time of day, day of week, 
date, location of purchase, purchaser, cash back amount, type of payment device, and the like. The 
transaction processor also organizes and submits one or more electronic ACH debits associated with the 
transaction to the clearinghouse system. 

Moreover, in an embodiment similar to that disclosed with reference to enrollment transaction 

20 requests, the transaction processor processes transaction requests by validating some or all of the submitted 
user data, by clearing some or all of the user data through negative and/or positive databases, by assessing a 
risk score to the enrollment transaction, by settlement through electronic ACH debit processing, or the like. 
The transaction processor retums an authorization result of the purchase transaction to the merchant As 
disclosed in the foregoing, the fomiat and content of various infonnation within the authorization result may 

25 depend on whether the transaction processor will act as a guarantor for the payment transaction. As 
disclosed, the authorization result can include advice or instmctions on whether to an accept or decline the 
purchase transaction, a risk score to infomi the merchant of a risk associated with accepting the transaction, a 
result of a negative and/or database search, or the like. 

When the transaction processor processes purchase transaction requests that include settlement, 

30 the transaction processor can send a report, often in the fomn of a settlement file, to the merchant. For 
example, when the transaction processor processes one or more (e.g., a batch of) transactions, the 
transaction processor may send a preliminary settlement report which is often subject to reversal. Similar to 
paper check processing, electronic check processing often assumes that transactions are settled, but then 
reverses a transaction when debits and/or credits fail during processing by a clearinghouse system, such as 

35 the ACH. The foregoing settlement file may be sent after one or moro transactions have been processed, one 
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or moie batches of transactions have been processed, one or more transaction or batches of transactions 
have been processed for a given merchant some time delay after processing, or the like. Moreom. the 
settlement file may be sent at intervals of time, at the end of each day. week, or the like. An artisan will 
recognize from the disclosure herein, that when the transaction processor acts as a guarantor for a 
transaction, the data related to that transaction in the settlement file is often then not subject to reversal 
because the risk of a failed settlement has been transfened to the transaction processor. 

Thus, the foregoing transaction processing system advantageously allows the association of a 
merchanf s payment device to a use^s checking account. The transaction processing system provides for 
enrollment of the user and the processing of purchase transactions. During enrollment and purchase 
transaction request processing, the transaction processor can perfomi various services, often chosen through 
preexisting agreements with merchants, such as user data validation, negative and positive datebase 
searching, risk assessments, validation or settlement processing, or the like. 

To facilitate a complete understending of the Invention, the remainder of the deteiled description 
describes the invention with reference to the drawings, wherein like reference numbers are referenced with 
15 like numerals throughout. 

FIGURE 1 illustrates a diagrammatic representetion of an exemplary embodiment of a transacthm 
processing system 100 which processes transactfons for merchants associated with payment technologies 
that debit funds of. for example, a user's checking account. As shown in FIGURE 1. the transaction 
processing system 100 includes a merchant system 105 designed to communicate with a user enrollment 
system 110. a transaction processor 115. and a user payment device 120. FIGURE 1 also shows the 
trans actfon processor 115 com muni cating wHh a clearinghouse sy stem 125. Ac^dLnglo^one embodiment. 
at teast the merchant system 105. the user enroNment system 110. the transaction processor 115. and the 
clearinghouse system 125 communicate with one another through one or more communication links. 

As disclosed in the foregoing, the user enrollment system 110 communicates with the merchant 
system 105 to enroll users into modem payment technologies. The modem payment technologies avoid the 
drawbacks of traditional credit or debit card technologies by associating a debit account 130. such as a 
checking account, witf, tfie user payment device 120. During enrollment, the user uses the enrollment system 
110 to submit various infomiation to the merchant system 105. The merchant system 105 organizes the 
infomiation into an enrollment transaction request and submite the enrollment transaction request to the 
tiansaction processor 115. The transaction processor 115 perfomis various merchant^lected services, 
such as those disclosed in foregoing, and returns an enrollment result to the merchant system 105.' 
Depending upon the enrollment result, ttie merchant system 1 05 may enroll the user by issuing to tfie user the 
user payment device 120 and associating tfie device to. for example, that user's debit account 130. 

When the user desires to make a purchase from tfie merchant, tfie user presents tfie user payment 
device 120. and Oie merchant system 105 uniquely identifies tiie debit account 130. The merchant system 
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105 submits a purchase transaction request and submits the purchase transaction request to the transaction 
processor 115. The transaction processor 115 perfomis various merchant-selected services, such as those 
disclosed in the foregoing, and returns an authorization result to the merchant system 105. Depending upon 
the authorization result, the merchant system 105 may complete the purchase by providing the products to 
the user and infomiing the transaction processor 115 of the same. The transaction processor 115 then 
advantageously perfomis settlement through the issuance of one or more electronic ACH debit transactions to 
the clearinghouse system 125, thereby transfening funds from the debit account 130 to a credited account 
.135, such as, for example, the merchant's bank account 

According to embodiments where the user payment device 120 communicates through, for example, 
a wireless signal, the merchant system 105 may include a merchant receiver 140 designed to receive the 
foregoing communications. 

MERCHANT SYSTEIV1 105 

According to one embodiment, the merchant system 105 includes the components be used to 
implement a system which uniquely identifies a detiit account when a user presents payment devices other 
than paper checks or credit cards. For example, the merchant system 105 may include one or more central 
server systems 142, which can communicate with one or more merchant receivers 140, one or more user 
account databases 144 and with electronic documents 146. The user account databases 144 can store 
various user data including MICR data which can be used to identify the debit account 130, and the 
associated device identifier (*'ID') the merchant system 105 will use to recognize the user payment device 
120. For example, as described in the foregoing with respect to enrollment, the user can provide MICR data 
from a check that conesponds to the account from which funds are to be drawn, such as, for example, the 
debit account 130. The MICR data can include a routing or bank transit number, generally identifying the 
financial institution or groups of financial institutions that issued the original useKs check, an account number 
against which the original check is drawn, a check sequence number, various separator symbols often unique 
to the financial institution, and the like. In addition, the MICR data can indicate whether the check is a 
company check or a personal check. The device ID can include an identification number or account number 
which uniquely identifies each user's debit account 130, which may also be used by the server 142 to index 
other data in the user account databases 144. 

The user account database 144 may also; include user enrollment data, such as the name, email, 
address, login identifier, password, or the like of each user. The infomiation may also include historical data 
fore each user, such as transactions, purchases, payments, risk scores, credit histories or other financial 
infonnation. public record data, or the like. 
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'"^«'"'»^''^'««^«'«*«en'o"'"entsyst^^ 
5 the Internet the sender 142 can also Include a web server accessing the electronic documents 146 The 
server 142 generally processes requests for the documents 146. retneves the documents 146. performs any 
necessary processing, and sends the documents 146 to the request computer system via the computer 
network. The documents 146 can be used to generate the electronic enrollment pages, user pages helpful in 
managing user accounts, or the like. Moreover, the documents 146 can be used to generate a variety of 
pages, such as search and other navigational pages, login, authentication, and authorization pages online 
stores, and so forth. 

Although the merchant system 105 is disclosed with reference lo one embodiment of Internet 
enrollment, the invention is not intended to be limited thereby. Rathe, an artisan wiB r^nlze from the 
'''^'^'^^"^hereina^^denumberofaltematlvesystemsp.DvkJin^ 
15 enrollmentviathemail.atelephonecafl.afacslmlle.ortheBke. Often, the enrollment vehicle opfions are 
hmrted by rules of the financial Instituttons governing portions of the transaction, such as. for example nrles 
generated by the Nafional Automated Clearing Housg Association ("NACHA^ or by the national ACH networi. 
Additional lnfom«tion on the processes employed by «,e ACH. mles of the NACHA. tiie process of clearing 
P^P^'^'^'^andapplylngpredfctivescoringalgoritt.msforriskassessmem^ Pat No 

20 5.679.940. Issued to Templeton et al. on October 21, 1997. ehtitied 'Tr^nsacbon System m On/Off Una 

knowledge possessed by one of ordinary skill in flie banking community. 

In addition, the merchant system 105 can include or comprise any device tiiat interacts witf, or 
provides data to the merchant receiver 140. the user enrollment system 110. or the transaction processor 
115. including by way of example, any Internet site, private networics. networic servers, video delivery 
systems, audto-vlsual media providers, television programming providers, telephone switehing networics. teller 
networics, wireless communication centers or the like. 

Moreover, the merchant system 105 may include one or more satellite or store computer systems 
throughout a geographically diverse networic. Each store system may be tocated wifl^in pm^dmity to a 
30 merchant receiver, and may advantageously communicate witt, one or more servers or the server system 142 

toaccessuserinfomiation stored In oneormoredatebasecoltections. such as. forexample.^ 
datebase144. 
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USER ENROLLMENT SYSTEM 110 

FIGURE 1 also shows the transaction processing system 100 comprising the user enrollment system 
110. According to one embodiment, the user enrollment system 110 comprises one or more computer 
systems allowing a user to interact with the merchant system 105 via a communication link. In one 
5 embodiment the computer is equipped with a modem or other communication device configured to 
communicate with aspects of the merchant system.105. The computer may comprise, by way of example, 
processors, program logic, or other substrate configurations representing data and instnictions, which operate 
as described herein. In other embodiments, the processors can comprise controller circuitry, processor 
circuitry, processors, general purpose single-chip or multi-chip microprocessors, digital signal processors, 
10 embedded microprocessors, microcontrollers and the like. In addition, the user enrollment system 110 can 
comprise a computer workstation, a local area network of individual computers, a kiosk, a point-of-sale 
device, a personal digital assistant, an interactive wireless communications device, an interactive television, a 
transponder, or the like. 

In one embodiment, the user employs the user enrollment system 1 10 to enroll with the merchant 

IS system 105. For example, the merchant system 105 may advantageously present an electronic enrollment 
form to the user through the user enrollment system 110. The enrollment torn can Include an entry for data 
associated with the debit account the user wishes to tie to the payment device 120, such as, for example, 
MICR data from an unused check. According to one embodiment, the enrollment fomi may also Include an 
explicit authorization fifom the user, authorizing the merchant, the processor, or both, to generate electronic 

20 debits and credits from a selected user debit account. 

When the user has completed the eriroltment fonn, the user enrollment system 110 transfers the 
entered infomfiation to the merchant system 105, where it is stored, for example, in the user account database 
144. An exemplary enrollment process is disclosed with reference to FIGURE 3. 

Although the enrollment system 110 is disclosed with reference to an embodiment of Internet 

25 enrollment, the invention is not intended to be limited thereby. Rather, as disclosed, a wide number of 
alternative systems can provide user enrollment, such as, for example, user enrollment via the mail, a 
telephone call, a facsimile, or the like. Often, the enrollment vehicle options are limited by rules of the 
financial institutions goveming portions of the transaction, such as, for example, rules generated by NACHA 
for the national ACH networi(. 

30 FIGURE 1 also shows the merchant system 105 including server code 148. The server code 148 

advantageously Includes one or moro software processes or program logic designed to execute on the server 
systems 142. In one embodiment, the sen/er code 148 may advantageously include software or hardware 
components such as software object-oriented components, class components and task components, 
processes methods, functions, attributes, procedures, subroutines, segments of program code, drivers. 

3S fimiware, microcode, circuitry, data, databases, data stnictures. tables, anays, and variables. As illustrated in 
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FIGURE 1. the server code includes enrollment process code for entolllng users into the transaction 
processing system 100. and purchase process code for allowing users to purchase products by presenting 
their user payment devices 120. 

TRANSACTION PROg PSSnp n«; 

According to one emIxMJiment, the transaction processor 115 comprises one or more server systems 
152 communicating with one or more database collections to detemiine whether to authorize particuiar 
transactions presented by the merchant system 105. The database collection can comprise one or more 
logical and/or physical data storage systems for storing the data used by the transaction processor 115, and 
may comprise two or more separate databases and/or storage systems or networi<s of storage systems. 

As shown in FIGURE 1, the database collection comprises a historical transaction database 154. arid 
a MICR line conversion database 156. The historical transaction database 154 advantageously stores 
infomiation about the users* financial history, and may Include transaction data from transactions processed 
by the transaction processor 115. otfier systems, credit reporting companies, or other commerciafly available 
databases. The historical transaction database 154 can include Infbnnation from, for example, credit reports, 
online activities by the user, other user data, or the like. The historical transaction database 154 can 
comprise multiple databases, such as. for example, a positive database storing positive risk Information, and 
negative databases storing high-risk infomiation or names of otheniirise unqualified indivMuals. 

The MICR line conversion database 156 Includes infomiation regarding the fomiatting of transactions 
submitted to the clearinghouse system 125. For example, tfie II^ICR line conversion database 156 can 
include hfetoric al and other infomiation reganiing tt ie placement^nd use ofdiffering MICR characterLby^ 
various banking institutions or check printing companies, ttiereby providing tiie transaction processor 115 witti 
conversion infomiation for converting the user entered checking account data, such as ttie MICR line, into, for 
example, electronic ACH debit or credit transactions. The MICR data and/or historical data stored In tiie 
25 MICR line conversfon database 154 can also include routing numbers, account or check number, payable 
through credit institutions, traditionally absent numbers, or the like. 

FIGURE 1 also shows tfie transaction processor 115 including server code 158. The server code 
158 advantageously includes one or more software processes or program logic designed to execute on the 
server systems 152. In one embodiment, tiie sen/er code 158 may advantageously Include software or 
30 hardware components such as software otqect-oriented components, dass components and task 
components, processes metfiods, functions, attributes, procedures, subroutines, segments of program code, 
drivers, flmiware, microcode, circuitry, data, databases, data structures, tables, anays. and variables. 

As shown in FIGURE 1, tfie server code 158 includes transaction process code, and enroOment and 
purchase processing code. The hansaction process code advantageously peribmjs various merchant 
selected services, such as. for example, user data validation, negative and/or positive database searching. 
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risk scoring, account infomiation validation, settlement processing, or the like. The transaction process code 
also returns enrollment and authorization results. As disclosed, various information within the authorization 
result may depend on whether the transaction processor will act as a guarantor for the payment transaction. 
As disclosed, the authorization result can include advice or instructions on whether to an accept or decline the 
payment transaction, a risk score to inforni the merchant of a risk associated with accepting the transaction, a 
result of a negative and/or database search, or the like. 

USER PAYMENT DEVICE 120 

As disclosed in the foregoing, the user payment device 120 allows users to make purchases by 
presenting the device 120 to the merchant system 105, and having the appropriate funds withdrawn from the 
debit account 130. According to one embodiment, the user payment device 120 can comprise a wide variety 
of point-of-sale payment devices. For example, the user payment device 120 can comprise radio or other 
frequency transponders, such as toll transponders designed to automatically communicate with tollbooths, 
thereby avoiding the need to stop and pay cash to use a toll road. The user payment device 120 may 
comprise transponders designed to communicate with gas stations for the payment of fuel at the pump. 
Transponders may be used to conveniently pay for drive through services, grocer checkout counters, or 
virtually any place where payment through a wireless device makes for convenient, efficient, purchases. 
According to one embodiment, the user payment device 120 can comprise a computing device, a personal 
digital assistant, a wireless telephone or the like. Moreover, according to one embodiment, the user payment 
device 120 transmits various data when it detects the presence of a receiver for the same. Other 
embodiments may include the ability to receive data from or othen/vise communicate with, for example, the 
merchant system 105. 

According to another embodiment, the user payment device 120 may comprise toyalty cards such as 
those used by many grocers, or the like. In such embodiments, the user payment device 120 may include a 
magnetic stripe and/or number designed to uniquely identify the debit account 130. AcconJing to yet anottier 
embodiment, the user payment device 120 may comprise biometric solutions such as those used by quick 
serve restaurants including thumbprints, facial recognition, or the like. Other embodiments include electronic 
wallets, one or more smart cards, or the like. 

As disclosed in the foregoing, the user payment device 120 can advantageously be associated with 
the merchant, and therefore, can often generate loyalty in customers as they desire to use their device 
instead of canying cash or using expensive credit card technologies. 

CLEARING HOUSE NETWORK 125 

According to one embodiment, the clearinghouse system 125 comprises the national ACH network. 
Generally, the ACH networi( can accept electronic ACH debit and credit transactions against, for example, the 
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usefs debit account 130. When the transactiori piocessor 115 settles a transaction between the user and the 
merchant, the transaction processor 115 advantageously fonnats at least one electronic ACH debit 
transaction debiting the user's debit account 130. and crediting the credited account 135. The foregoing 
electronic ACH debit and credit transactions are then transfened into the national ACH network as electronic 
transactions. Rules for the fbnnat and content of the electronic ACH debit and credit transactions are 
governed by NACHA and considered within the scope of knowledge for an artisan within the electronic 
banking industry. 

Although the clearinghouse system 125 is disclosed with reference to this embodiment the invention 
is not intended to be limited thereby. Rather, a skilled artisan will recognize from the discbsure herein a wkle 
number of alternatives for the clearinghouse system 125. For example, the clearinghouse system 125 may 
comprise one or more private institutions that have devetoped a networic for dearing elec^ 
between users thereof. Such private systems generally promulgate mles governing the type and content of 
electronic transaction submissions. 

15 MERCHANT RECFIVFP un 

FIGURE 1 also shows the transaclfon processing system 100 including the merchant receh«r 140. 
The merchant receiver 140 communicates with, or receives the faansmisston from, the user payment device 
1 20. The merchant receiver 140 may be a toll receiver designed to automatically read a toll transponder of a 
motarist. may be a receiver designed to read a transponder waved in front of, for example, a fuel pump, or the 
20 like. According to one embodiment, the receiver 140 communicates with the merchant system 105 to 
unki uely ktentH y the user, the "sgs checking account date, biometric readers or scanners, or the like. 

Other embodiments may include a magnetic stripe reader or other system designed to read the 
Infomnation found on loyalty cards or the like. 
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COMMUNICATIOKf I IMKg 

FIGURE 1 also illustrates various components communicating with one another through 
communication links. In one embodiment, the communications links include portions of the Internet, which is 
a global networi< of computers. In other embodiments, the communications links may be any communication 
systerii including by way of example, telephone networi®. wireless date transmission systems, two-way cable 
systems, computer networics. interactive kk>sk networi<s. aufomatic teller machine networks, interactive 
television networics, and the like. 

Based on the foregoing disclosure, the transaction processing system 100 advantegeously provkles 
users with the convenience of using the payment devices 120 instead of canying cash or using expenshffi 
traditional card technologies. Moreover, the transaction processing system 100 advantegeously provides 
merchante with the ability to select from mny risk detemiining or risk guarantee services, white also allowing 
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for automated processing through the clearinghouse system 125, which is generally significantly less 
expensive than the minimum fixed cost fees associated with the traditional card technologies. 

Although the transaction processing system 100 has been disclosed with respect to various 
preferred and alternative embodiments, an artisan will recognize from the disclosure herein that a wide 
number of differing devices can accomplish the functionality disclosed. For example, the merchant system 
105 and the transaction processor 1 15 may advantageously be governed by, and/or comprise a single entity 
or system. Moreover, layered gateway systems may offer users the ability to use the gateway's payment 
device in multiple retail locations of multiple merchants, without departing from the scope of the present 
disclosure. 

EXEMPLARY ENROLLMENT FORM 

FIGURE 2 illustrates an exemplary webpage 200, which can be used to enroll the user Into the 
transaction processing system 100, according to an embodiment of the invention. As shown in FIGURE 2. 
the webpage 200 comprises user demographic infomiation 205, such as name, address, email, age, social 
security number, gender, or other historical or demographic information desired by the merchant or processor 
to, among other things, develop accurate risk assessments of the user. The webpage 200 also includes an 
account selection button 210. providing the user the ability to associate, for example, payments from the user 
device 120, to ttie debit account 130. According to one embodiment, the user can select his or her checking 
account. According to ottier embodiments, tiie user may select a credit card or other financial accounts. 

When the user desires to tie his or her payment device 120 to the debit account 130, ttie webpage 
200 also includes an entry section for entry of debit account data 215. As shown in FIGURE 2, the debit 
account data 215 can include MICR data from an unused check. According to one embodiment, the user may 
be prompted to enter an asterisk (*), or other placeholder character, in place of ttie non-numeric symbols ttiat 
are included in many MICR characters printed on a check. Altematively, the webpage 200 may include an 
interactive portion which allows users to select from a given set of non-numeric MICR symbols to be added to 
ttieir MICR data. Other embodiments may include instmctions on how to create and/or attach a scanned 
Image of an unused check, or a file containing data from a MICR line optical and/or magnetic reader. In such 
embodiments, ttie merchant or tiie processor may incorporate hardware and/or software components 
designed to Interact with such data to extract the MICR data, such as, for example, optical character 
recognition ("OCR") software, or ttie like. . As shown in FIGURE 2, ttie webpage 200 may request MICR data 
be entered twice, ttiereby advantageously allowing ttie merchant system 105 to compare each entry so as to 
ensure correct entiy ttiereof. 

Embodiments of the enrollment webpage 200 also include an auttiorization section 220, where ttie 
user expllcitiy authorizes the merchant system 105 and/or the transaction processor 1 15 to perfomi electronic 
ACH debit and credit transactions to his or her selected debit account -Such auttiorization may include a 
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separate button indicating the user has read and understands the same, may have limitations such as a -^t 
to exceed- limitation, or the like. In addition, the webpage 200 includes a submit button 225. which transleis 
the user-entered date from the user enrollment system 1 10 to the merchant system 105, 

Although the webpage 200 is disclosed with reference to an exemplary embodiment, an artisan will 
5 understend from the disclosure herein that the webpage 200 may include a wide variety of interactive buttons, 
fomis, updated electronic pages, menu selections, multimedia explanations or other presentations, or the lil<e. 
Moreover, the webpage 200 may request that the user upload a digital picture or scanned image of the user 
or various user documents, such as a driver's license, social security card, government ID. or the like. In 
addition, the webpage may include one or more printeble fomjs which a user can email, mail or fax to the 
10 merchant system 105. 

As disclosed in the foregoing, the transaction processing system 100 can include a wkle variety of 
other enrollment mechanisms, and the exemplary online enrollment form 200 Is not meant to limit the scope of 
thedisctosure. 

15 ENROLLMENT PROCESS 300 

FIGURE 3 illustrates an enrollment process 300. according to an embodiment of the imrentfon. As 
shown in FIGURE 3. the enrollment process 300 generally includes the user transferring various demographic 
and account date to the merchant system 105. whfch in one embodiment, fomiate an enrollment transactton 
reque^ to be processed by tte transactton prwessor 1 15. 

The exemplary enrollment process 300 begins at BLOCK 305. where the user enters the user date 
into the enrollment system 110. As descri bed in th e forego ing, the user date can include a user name, 
address, soctei security number, email, government Wentification, corporate identification logins, passwords. 
Wometric date such as a fingerprints or tedal scans, driver's license infomiation such as license number or 
the like, scans of some or all of the foregoing documents, outputs from magnetic stripe or other card readers, 
or other date helpful in assessing a risk associated with enrolling the user in the transaction processing 
system 100. 

At BLOCK 310. the user enters MiCR date from one of his or her checks associated with the debit 
account 1 30 from which funds can be drawn. As described in the foregoing, the MICR date can include MICR 
characters, such as an account number, the bank transit number, the check sequence number, type of check, 
and the like. According to embodiments diseased in the foregoing, the IVIICR date may also include 
placement holder characters in place of the non-numeric symbols that are included in their MICR One. or the 
like. According to one embodiment the MICR date read by a scanning or reading device and Entered into the 
enrollment system 110. 

At BLOCK 315. the user authorizes the merchant system 105 and the transactton processor 115 to 
submit etectronic ACH debite against the.debit account 130 when the user presente the user payment device 
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120 as payment for products. As disclosed in the foregoing, such authorization can be governed by mies 
promulgated by the clearinghouse system 1 25. 

At BLOCK 320, the merchant system 105 organizes various user*submittec( infomiatlon into an 
enrollment transaction request, and submits the same to the transaction processor 115. The fomi and fomiat 
of the enrollment transaction request can be designated or defined by the merchant system 105 and/or 
transaction processor 115, and according to one embodiment, can include infonnation identifying the 
merchant, identifying the user, date and time infonnation, infonnation designating the user's account data, 
such as MICR data, merchant information, or the like. The enrollment transaction request may also include 
additional infomfiation useful in assessing the risk of the user, such as, for example, a driver's license or social 
security number, address, credit card data, or other demographic or financial data. 

After the transaction processor 115 processes the enrollment transaction, such as, for example, 
acconjing to various disclosed merchant-selected services, the transaction processor retums an enrollment 
result. According to embodiments disclosed herein, the enrollment result provides an indication to the 
merchant system 110 of the risk associated with accepting the enrollment of the user in the transaction 
processing system 100. 

At BLOCK 325, the merchant system 105 conflmis the receipt of that result, and can further instruct 
the transaction processor 1 15 to validate the enrolling user's account infomnation. For example, the merchant 
system 105 may desire to ensure that the banks, financial institutions, or the like, associated with the debit 
account 130, support the submission of electronic ACH debit transactions. According to one embodiment the 
merchant system 105 instructs the transaction processor 115 to format and submit an electronic ACH debit 
and credit for equal amounts against the debit account 130, thereby validating that the account information 
supports electronic ACH processing. 

At BLOCK 330, the merchant system 105 receives the report from the transaction processor 115 
detailing, for example, the results of the validation of account infonnation, the risk associated with enrolling 
the user, pennission to enroll the user in embodiments where the transaction processor 115 acts as a 
guarantor, one or more settlement files, or the like. Upon receipt of the report, the merchant system 105 can 
advantageously detenmine whether to enroll the user into the transaction processing system 100. 

Based on the foregoing, the enrollment process 300 advantageously provides assurances to the 
merchant system 105 on whether the enrolling user is within an acceptable credit risk and whether the user- 
selected debit account 130 and associated banking institutions allow for electronic transactions through the 
clearinghouse system 1 25. 

Although disclosed with reference to preferred and altemative embodiments, an artisan will 
recpgnize from the disclosure herein that the enrollment process 300 may advantageously include portions or 
all of the foregoing functionality, without departing from the spirit or scope of aspects of the invention. 
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PURCHASE PROp PRfi^nn 

FIGURE 4 iHustrates a purchase piocess 400. according to an eml)odlment of the invenfion. As 
shown in FIGURE 4. the purchase process 400 generally Includes the user presenting the user payment 
device 120 to the merchant receiver 140 as payment for one or more products, where the payment is to be 
5 debited from the debit account 130. The memhant system 105 recognizes the payment device 120 
ddtemilnes the conesponding account infomiation. and fom,ats a purchase transaction request to be 
processed by the transaction processor 115. Based at least in part upon the processing by the trar»aclion 
processor 115, the merchant system 105 will detemiine whether to allow the user to purchase the one or 
more products using the payment device 120. 
1 0 The exemplary purchase process 400 begins at BLOCK 405. where the user presents his or her user 

payment device 1 20 to the merchant receiver 140 as payment for one or more products, where the payment 
IS to be debited from the debit account 130. As disclosed In the foregoing, the presentment may be of a 
transponder, a loyalty card, a blometrfc. a smart card or the Bke. to a corresponding system designed to read 
sufficient information to uniquely locate the conesponding account infomiation. such as. for example account 
15 Infomiation stored In the user account database 144. At BLOCK 410. the meithaht system 105 Identifies the 
user payment device 120. accesses the relevant account infomration. and fbmiais a pun:hase transaction 
request to be processed by the transaction processor 115. 

As described In the foregoing, the fom> and fomiat of the purchase transaction request can be 
designated or defined by the merchant system 105 and/or transaction processor 115. and according to one 
20 embodiment, includes infomiation identifying the merchant, identifying the user, date and time infomiation 
•'^'^J'^?"««"9 *1 account_date. judi_ as MICR data„product infomiation. amount^of- 
purchase. time of day. day of week, date, location of purchase, purchaser, cash back amount, type of 
payment device, and the like. The purchase transaction request may also include additional infomiation 
useful In assessing ttie risk of ttie transaction, such as. for example, a user driver's license or social security 
25 number, address, credit card data, or ottier demographic or financial data. 

After the transaction processor 115 processes ttie purchase transaction, such as. for example, 
acconling to various disclosed merchant-selected servK^s, ttie transaction processor 115 returns an 
authorization result. According to embodiment disclosed herein, ttie auttiorization result provkles an 
indication to ttie merchant system 105 of ttie risk associated witti accepting ttie transaction. According toone 
30 embodiment, when ttie auttiorization result was positive, or wittiin predetemiined acceptable ranges of risk, 
ttie merchant system 1 10 can finalize ttie purchase wltti ttie user. 

At BLOCK 420. ttie merchant system 105 confimis ttie receipt of ttie auttiorization result, and can 
fiirttier insttuct ttie transaction processor 115 whettier flie purchase was finalized between ttie usJr and ttie 
merchant system 105. When ttie purchase was finalized ttie merchant system 105 confimis receipt of ttie 
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authorization results and transmits an indication to the transaction processor 115 that the purchase was 
finalized and settlement should be processed. 

According to one embodiment, the transaction processor 115 uses the MICR conversion data from 
the MICR conversion database 156, to translate the MICR data into that infomiation desired by the 
clearinghouse system 125. The transaction processor 1 15 then fomoats and submits an electronic ACH debit 
which includes the foregoing infonnation, to the clearinghouse system 125. 

Based on the foregoing, the purchase process 400 advantageously advises, and often guarantees 
that the purchase transaction is within an acceptable credit risk for the merchant. l\4oreover, the purchase 
process 400 perfomis settlement processing. Although disclosed with reference to prefen'ed and altemative 
embodiment, an artisan will recognize from the disclosure herein that the purchase process 400 may 
advantageously include portions or all of the foregoing functionality, without departing from the spirit or scope 
of aspects of the invention. 

TRANSACTION PROCESS 

FIGURE 5 illustrates a transaction processing process 500, according to an embodiment of the 
invention. As shown in FIGURE 5, the transaction processing process 500 generally includes the transaction 
processor 115 receiving one of an enrollment transaction request or a purchase transaction request from the 
merchant system 105. Based on which sen^ices the merchant selected, the transaction processing process 
500 perfonns various levels of risk assessment and, in some cases, may guarantee the transaction. Thus, 
according to one embodiment, the actions of the transaction processing process 500 will vary depending upon 
the service selections of the merchant. The transaction processing process 500 also can validate various 
account information and/or perfomri settlement processing through communication with the clearinghouse 
system 125. 

According to one embodiment, the transaction processing process 500 begins at BLOCK 505 where 
the transaction processor receives one of an enrollment transaction request or a purchase transaction request 
from the merchant system 105. As described in the foregoing, when the menchant*selected services include 
one or more of user data validation, clearance of the negative and positive databases, assessment of risk 
scores, or flie like, the transaction processor 115 perfonns tiiose activities witii respect to the information 
provided in ttie particular transaction request, as lllustiBted in BLOCKS 510-520 of FIGURE 5. 

At BLOCK 525, ttie transaction processor 115 transmits the results of the foregoing processing back 
to the merchant system 105. As described, at BLOCK 530, the merchant system 105 confimis ttie receipt of 
ttie transaction results, and instmcts the transaction processor 115 to validate the account data associated 
witti an enrollment transaction request, settle ttie purchase associated witti a purchase ta^nsaction request, or 
ttie like. 
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When validation or settlement Is desired, at BLOCK 540. the transaction processor fbmiats the 
appropriate electronic ACH submissions by. ibr example, the convereion of the M\CR data into Infomiatioa 
used by the clearinghouse system 125. For example, the transaction processor 115 perfomis settlement by 
debiting the debit account 130 by an amount conesponding to the purchase transaction amount Moreover 
the transaction processor 115 submits a credit of the foregoing amount, minus in one embodiment, the 
processor's fees, to the credited account 135. At BLOCK 545, the transaction processor 115 submits the 
electronic ACH debits or credits to the clearinghouse system 125. At BLOCK 550. the transaction processor 
115 reports the results back to the merchant system 105. 

As disclosed In the foregoing, the reports can advantageously include one or more settlement files 
conesponding to one or more transactions or batches of transactions having been just processed or 
processed some time before. Also as disclosed, when the transaction.processor 115 acts as a guarantor for 
a particular transaction, the data related to that transaction in the settlement file Is often then not Subject to 
reversal. 

Based on «ie foregoing, tiie transaction processing process 500 advantageously employs the 
clearinghouse system 125 to settie payments made using the payment device 120. or validate account data 
submitted at enrollment. The clearinghouse system" 125 generally peribnns the setOement purohases ^r. 
more reliably, and at a significanfly lower rate than the fixed minimum and other fees of traditional credit 
cards. In similar feshion. the transaction processir^ system 100 disclosed in the foregoing advantageously 
adopts many of the conveniences lor users and merchants of credit card payments, without Incorporating the 
20 high costs of the same. 

AlttK)ugh flie foregoing invention has been described m temis of certain preferred fimhnHi»,.nts 
otfier embodiments wlU be apparent to ti,ose of ordinary skill in ttie art from the disclosure herein.' 
Additionally, other combinations, omissions, substitutions and modifications will be apparent to the skilled 
artisan in view of the disclosure herein. While certain embodiments of the inventions have been described, 
these embodiments have been presented by way of example only, and are not intended to limit ttie scope of 
the Inventions. Indeed, the novel mettiods and systems described herein may be embodied in a variety of 
otfrer fbmis without departing from the spirit tiiereof. The accompanying claims and ttieir equivalents are 
intended to cover such fomis or modifications as would fall within the scope and spirit of the Inventions. 

In addition to ttie foregoing disclosure, all publications, patents, and patent applications, or other 
references mentioned in this specification are hereiti incorporated by reference to the same extent as if each 
individual document was specifically and individually, indicated to be incorporated by reference. 
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WHAT IS CLAIMED IS: 

1. A financial transaction system configured to accept as payment for goods or sen/Ices the 
presentation by a payor of a payment device other than a paper check, a credit card or a debit card, the 

5 financial transaction system comprising: 

a payment device other than a paper check, a credit card or a debit card, where 
presentation of the payment device for goods or services indicates that funds are to be drawn on a 
checking account of a payor to pay for the goods or services in an electronic transaction; 

a point of sale device which receives from the payment device, identification data useable 
10 to uniquely identify the payment device; and 

one of more computing devices that assess risk wherein the one or more computing 
devices assess the risk of the electronic transaction, and accept or decline the payment for the 
goods and services. 

2. The financial transaction system of Claim 1, wherein the payment device comprises a 
IS transponder. 

3. The financial transaction system of Claim 1 , wherein the payment device comprises one or 
more toyaity cards. 

4. The financial transaction system of Claim 1, wherein the payment device comprises one or 
more smart cards. 

20 5. The financial transaction system of Claim 1. wherein the payment device comprises a 

computing device. 

6. The financial transaction system of Claim 5. wherein the payment device comprises a 
personal digital assistant. 

7. The financial transaction system of Claim 1, wherein the payment device comprises a 
25 mobile telephone. 

8. The financial transaction system of Claim 1 , wherein the payment device comprises one or 
more biometric elements. 

9. The financial transaction system of Claim 1 , wherein the payment device comprises one or 
more devices storing or using biometric data. 

30 10. The financial transaction system of Claim 1, wherein the point of sale device comprises a 

wireless receiver. 

11. The financial transaction system of Claim 1, wherein the point of sale device comprises a 
magnetic strip reader. 
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12. The financial transacbon system of Oaim 1. wherein the one or more computing devices 
include gateway computing devices which allow secondary merchants to accept presentation of the payment 
device for goods and sendees. 

13. The financial transaction system of Claim 1. wherein the electronic transaction Includes an 
enrollment transaction designed to detemiine whether the payor meets predetemiined criteria set by the 
financial transaction system. 

14. The financial transaction system of Claim 1, wherein the one or more computing devices 
receive results fliom a transaction processing system. 

15. The financial transaction system of Claim 14. wherein the resulte include an authorization to 
accept the presentation of the payment device as payment for the goods or services. 

16. The financial transaction system of Claim 14, wherein the results include an authorization to 
enroll the payor with the financial transaction system by providing the payor with the payment device. 

17. The financial transaction system of Claim 1 wherein the one or more computing devices 
comprise: 

a server system including a merchant receiver configured to recognize the payment device 
presented bythe useraspaymentforgdodsorservices,and 

one or more datebases storing MICR data used to identic the checking account 

18. The financial transaction system of Claim 1 further comprising: 
identification infomtation conversion date usable to convert the identification data into 

infomiation used by a clearinghouse system to perfbmi electronic check processing; and 
historical trarwaction date usabte to assess the risk of pe^ 

19. the financial transactkm system of Claim 1. wherein the one or more computing devices 
perfomi settlement processing. 

20. The financial transaction system of Claim 1. wherein the one or more computing devfces 
25 pertonn validation processing. 

21. A method of accepting a payment device as payment for goods or services, the method 
comprising: 

receiving identification infomiation from a payment device presented by a user for payment 
of goods or services, wherein the payment device is not a paper check, a credit card, ore debit card; 

detemiining checking account date associated with the payment device whereiii 
presentation of the payment device indicates that funds are to be drawn on a checking account of 
the user; 

initiating an electronic transactfon using the checking account data; 
obtaining an assessment of a risk of the electronic transaction; and 
accepting or declining the payment for the goods or services. 
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22. The method of Claim 21, further comprising enrolling the user by issuing the payment 
device and obtaining the checking account data. 

23. The method of Claim 22, further comprising obtaining an assessment of a risk of enrolling 

the user. 

24. The method of Claim 22 further comprising acquiring information identifying the user 
attempting to enroll into a system providing for the payment goods or services from the checking account of 
the user through the presentation of the payment device. 

25. The method of Claim 24. wherein the infomiation includes information found on the user's 
driver's license. 

26. The method of Claim 24, wherein the infomiation includes demographic information. 

27. The method of Claim 24 wherein [he infonmation includes biometric infomiation. 

28. The method of Claim 24, wherein the infomiation includes password infbnnatidn. 

29. The method of Claim 21, wherein the assessment of the risk is acquired through a 
transaction processor 

30. The method of Claim 21 wherein obtaining the assessment of risk is based on one or more 
characteristics of the electronic transaction 

31 . The method of Claim 30 wherein the checking account infomiation comprises MICR data. 

32. The method of Claim 31, wherein the one or more characteristics of the electronic 
transaction include whether the MICR data Is valid. 

33. The method of Claim 31, wherein the MICR data is valid when it can be converted into 
infomiation used by clearinghouse systems to transfer funds. 

34. The method of Claim 30, wherein the one or more characteristics of the electronic 
transaction include whether an assessed risk of the electronic transaction is within predetemiined parameters. 

35. The method of Claim 34, wherein the assessed risk includes an evaluation of historical 
transaction infomiation. 

36. The method of Claim 35, wherein the historical transaction infonnatibn includes negative 
transaction infomiation. 

37. The method of Claim 35, wherein the historical transaction infomiation includes positive 
transaction infomiation. 

38. The method of Claim 30, wherein the one or more characteristics of the electronic 
transaction include whether the electronic transaction will be guaranteed. 

39. The method of Claim 21 , further comprising transmitting MICR data to a gateway system. 

40. The method of Claim 21, further comprising transmitting Information to a gateway system, 
and wherein the gateway system detennines whether to accept or decline the electronic transaction, 

41 . The method of Claim 21 , wherein the payment device comprises a transponder. 
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